feat: Quality pack targets - #277
Conversation
Add 14 comp_reqs across the 7 components (3 per component) Mark implementing sources with `// # req-Id:` and expose them via per-component `requirement_marked_sources` filegroups Wire `code_targets` in each component's docs/BUILD Annotate 3 tests with FullyVerifies/TestType/DerivationTechnique and tag cc_tests as `unit` / `component` Add //:unit_tests and //:component_tests aggregate suites Add docs/quality_pack.rst documenting the pack and baseline
License Check Results🚀 The license check job ran with the Bazel command: bazel run //:license-checkStatus: Click to expand output |
|
Coverage report for this pull request: Status: failure (workflow run) The archive contains the HTML report, the raw LCOV data and the JUnit XML test results. |
…targets # Conflicts: # score/gateway_ipc_binding/test/BUILD # score/serializer/BUILD.bazel # score/socom/test/stress/BUILD # score/socom/test/unit/BUILD
| @@ -0,0 +1,121 @@ | |||
| .. | |||
| # ******************************************************************************* | |||
There was a problem hiding this comment.
This .rst does not fit the S-CORE module template. docs/ is defined as features/, module/ and verification_report/; there is no place for a standalone document at the docs root.
Beside this placement, the content is build and usage instructions rather than module documentation, so README.md is the correct place in my opinion . That readme already have the coverage part
I suggest move this a into the README.md in a section, next to the existing "Coverage report" one:
## Quality pack
Requirements traceability is produced by the documentation build. Run the tests
first: the docs build reads `bazel-testlogs` to link each requirement to the
tests that verify it.
```sh
bazel test //:unit_tests //:component_tests
bazel run //:docs
```
This generates:
- `_build/index.html` — documentation, showing the source-code and test
links on each requirement
- `_build/needs.json` — the requirements model
- `_build/metrics.json` — traceability metrics
To print the traceability summary on the command line:
```sh
bazel run //:traceability_gate -- --metrics-json "$PWD/_build/metrics.json"
```
| Functional Requirements | ||
| ----------------------- | ||
|
|
||
| .. comp_req:: FlatBuffers gateway configuration schema |
There was a problem hiding this comment.
The PR description scopes requirements to the SOME/IP protocol specification. These are derived from the existing implementation instead, so they fall outside that scope — please remove them.
| Functional Requirements | ||
| ----------------------- | ||
|
|
||
| .. comp_req:: Symmetric IPC binding with split control and payload planes |
There was a problem hiding this comment.
The PR description scopes requirements to the SOME/IP protocol specification. These are derived from the existing implementation instead, so they fall outside that scope — please remove them.
| Functional Requirements | ||
| ----------------------- | ||
|
|
||
| .. comp_req:: Bridge local IPC and remote SOME/IP service instances |
There was a problem hiding this comment.
The PR description scopes requirements to the SOME/IP protocol specification. These are derived from the existing implementation instead, so they fall outside that scope — please remove them.
| Functional Requirements | ||
| ----------------------- | ||
|
|
||
| .. comp_req:: Null-passthrough serializer for pre-serialized payloads |
There was a problem hiding this comment.
The PR description scopes requirements to the SOME/IP protocol specification. These are derived from the existing implementation instead, so they fall outside that scope — please remove them.
| Functional Requirements | ||
| ----------------------- | ||
|
|
||
| .. comp_req:: Service-oriented communication runtime |
There was a problem hiding this comment.
The PR description scopes requirements to the SOME/IP protocol specification. These are derived from the existing implementation instead, so they fall outside that scope — please remove them.
| Functional Requirements | ||
| ----------------------- | ||
|
|
||
| .. comp_req:: SOME/IP protocol type and constant definitions |
There was a problem hiding this comment.
The PR description scopes requirements to the SOME/IP protocol specification. These are derived from the existing implementation instead, so they fall outside that scope — please remove them.
| Functional Requirements | ||
| ----------------------- | ||
|
|
||
| .. comp_req:: SOME/IP Service Discovery handling |
There was a problem hiding this comment.
The PR description scopes requirements to the SOME/IP protocol specification. These are derived from the existing implementation instead, so they fall outside that scope — please remove them.
…targets # Conflicts: # .github/workflows/ci.yml
Head branch was pushed to by a user without write access
|
Documentation preview for this pull request is available at: |
|
Quality pack traceability report for this pull request: Status: UNAVAILABLE (workflow run) |
@GabrielPinheiro7891 Can you monitor if the added workflows work as expected? |
Yes, i am checking why it appears as UNAVAILABLE. The CI worked fine and generated the metrics.json. trying to see what happened. |
So, it's using the link to an old workflow run in the comment posted instead of using the last build which was used to create the comment. #1544 instead of #1555.. |
|
This one seemed to have worked: #177 (comment) |
I believe its working fine. This one just tried to pull an old workflow, which is strange, it should pull the workflow of the run it was called upon, but as you saw on other pr it seems its working fine. |
3 participants
Requirements are the SOME/IP protocol specification. Check if we can use/import the openly available protocol spec.
AUTOSAR spec cannot be used due to IP.